The exploitation of memory corruption vulnerabilities in server and client applications has been one of the prevalent means of system compromise and malware infection. By supplying a malicious input to a target application, an attacker can inject and execute arbitrary code, known as shellcode, in the context of a vulnerable process.
The prevalence of code injection attacks has led to the wide adoption of exploit mitigations based on non-executable memory pages, such as Data Execution Prevention (DEP), in recent versions of popular operating systems.
In turn, attackers are increasingly relying on return-oriented programming (ROP) to bypass these protections. ROP allows the execution of arbitrary code on a victim system without the need to inject any code. ROP relies on the execution of code that already exists in the executable address space of a process, but, instead of executing the code of a whole library function, ROP is based on the execution of a combination of tiny code fragments, dubbed “gadgets,” scattered throughout code segments of the process. The execution order of the gadgets is controlled through a sequence of gadget addresses that is part of the attack payload. This means that an attacker can execute arbitrary code on the victim system by injecting only control data.
During an attack, each gadget called by an ROP payload transfers control to the next gadget through indirect control transfer instruction that reads the sequence of gadget addresses contained in the injected ROP payload.
In order for the ROP payload to be able to control the execution of these gadgets using the gadget addresses stored in the ROP payload, the gadgets selected by the ROP payload are typically stored in non-volatile portion of executable memory space. For example, such a non-volatile portion of executable memory space would typically not be subject to address space layout randomization (ASLR). The executable memory space in which the gadgets are present can be referred to as gadget address space.
An example of an ROP payload and how it controls the execution of gadgets is shown in FIG. 1. As shown, an ROP payload can exist in data memory starting at an address X and each n byte(s) of data can be a new piece of the payload, where n is the address size used in the target system (e.g., such as four bytes). The instruction pointer (EIP) and the stack pointer (ESP) of the target system can be controlled by the ROP payload to cause it to call the desired gadgets.
More particularly, for example, initially, EIP and ESP may be initialized with values of 070072F7 and a memory address of X+n*1 as shown in FIG. 1. Any suitable mechanism can be used to give EIP and ESP these values. For example, a stack pivot instruction sequence can be used to set EIP and ESP.
This will cause the first gadget call (marked “1st” on the right side of FIG. 1) to occur. As shown, during this call, a “pop eax” instruction and a “ret” instruction are executed. The “pop eax” instruction causes the value (0x0010104) at the address (X+n*1) pointed to by the stack pointer (ESP) to be copied to register EAX, and causes ESP to be incremented by one memory address size (e.g., four bytes, assuming an address size of 32 bits). The “ret” (return) instruction causes the value at the address pointed to by the stack pointer (ESP) to be put into the instruction pointer (EIP) and causes ESP to be incremented by one address size. This “ret” command thus sets up the next gadget call (marked “2nd” on the right side of FIG. 1) at address 070015BB by setting the instruction pointer with the value (070015BB) at the address X+n*2 pointed to by ESP. Other gadget calls (marked “3rd,” “4th,” and “5th” on the right of FIG. 1) can then be performed in the order specified by the addresses specified in the ROP payload. As can be seen, this allows ESP to be used as an “index” register for transferring control to the desired gadget according to the list of gadget addresses in the ROP payload.
Although gadgets may end with a “ret” instruction as shown in FIG. 1, other indirect control transfer instructions may also be used.
Accordingly, mechanisms for detecting return-oriented programming payloads are desirable.